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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 

The present document is part 3 of a multi-part deliverable covering Regenerative Satellite Mesh - A (RSM-A) air 
interface MAC/SLC layer specification, as identified below: 

Parti: "General description"; 

Part 2: "MAC layer"; 

Part 3: "SLC layer". 
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Scope 



The present document defines the communication interface between a TC-SES BSM Regenerative Satelhte Mesh-A 
(RSM-A) air interface compliant Satellite Terminal (ST) and the Security Access Module (SAM). It specifies the 
communication medium and the protocols for communication. This document describes how packets, received at the ST 
from the Network Operations Control Centre (NOCC), are routed to the SAM, how messages created originally by the 
ST are routed to the SAM, how message from the SAM are routed via the ST to the NOCC and how messages from the 
SAM are consumption by the ST. 
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3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Network Operations Control Centre (NOCC):centre that controls the access of the satellite terminal to an IP network 
and also provides element management functions and control of the address resolution and resource management 
functionality 

satellite payload: part of the satellite that provides air interface functions 

NOTE: The satellite payload operates as a packet switch that provides direct unicast and multicast 
communication between STs at the link layer. 

Satellite Terminal (ST): terminal that is installed in the user premises 

terrestrial host: entity on which application level programs are running 

NOTE: It may be connected directly to the Satellite Terminal or through one or more networks. 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ACF Access Control Field 

BA Bandwidth Assignment 

BCSTID Bandwidth Control Satellite Terminal IDentity 

BR Bandwidth Request 

BRIC Bandwidth Request Integrity Check 

IP Internet Protocol 

LSB Least Significant Bit 

MAC Medium Access Control 

Mbps Mega-bits per second (millions of bits per second) 

MSB Most Significant Bit 

NOCC Network Operations Control Centre 

RSM Regenerative Satellite Mesh 

SAM Security Access Module 

SAP Service Access Point 

SI-SAP SatelHte Independent-SAP 

SLC Satellite Link Control 

SOF Start Of Frame 

ST Satellite Terminal 

TOD Time Of Day 

UDP User Datagram Protocol 

USB Universal Serial Bus 



4 General aspects 

4.1 Security Access IVIodule - functional description 

The SAM is the security component of a satellite terminal. Physically it is a secure chip embedded in the terminal. The 
SAM contains secret key material and authenticates every RSM-A packet sent out by the terminal by generating an 
Access Control Field, which can be verified by other authorized components of the system. The SAM will only sign 
requests that are valid within the policies set forth for that particular ST. On the receive side it verifies that management 
messages are authentic messages from the NOCC. The set of functionality, including the ACF generation, bandwidth 
assignment and bandwidth request integrity checks, is called capacity protection and is introduced in TR 102 287 (see 
bibhography). 



SATELLITE TERMINAL 



SATELLITE TERMINAL 




T interface 



SAM-ST interfaci' 



RSM-A Air interface 



Figure 4.1 : Protocol architecture and SAIVI-ST interface 
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The SAM's areas of responsibility to the RSM-A system are as follows: 

• Authentication. 

• Authorization protection. 

• Registration. 

• Usage audit. 



Inputs to 
the SAM 



Outputs 

from the 
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Request for 
Bandwidth 
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Request for 
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Traffic 
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Allocation 
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Security 
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Audit data 



Management 
Information 
for NOCC 



Management 
Information 
from NOCC 



Bandwidth 

request 

Integrity Check 



Figure 4.2: Security function interactions between the SAIV! and the ST 



ST-SAM physical interface 



The ST-SAM physical interface is divided into an electrical interface and a mechanical interface. 

The physical/electrical interface between the ST and the SAM shall be a Universal Serial Bus (USB) revision 1.1 [5]. 
The SAM shall be equivalent to a "USB device" function and the ST shall be equivalent to a "USB host". The ST 
implementation shall not require the SAM to share this USB port with any other device or hub. The ST should suppress 
frame timing, i.e. should not send USB Start Of Frame (SOF) token timing packets on the USB interface. 



The physical/mechanical interface may use any suitable interface. An optional mechanical description is given in 
annex A. 
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Figure 5.1 : Interlayer communications model 



6.1 



Client - Function interface 



Procedures 



The ST and SAM shall use the messages described in the procedures below to commurucate with each other. Whenever 
the ST sends the SAM an INDICATION message, the SAM shall always respond with either a RESPONSE message 
(for a successful operation) or a FAILURE message (whenever the requested operation fails) with an error code. 
However, the SAM does not respond to the ACF FRAME COUNT INDICATION message. 



6.1.1 



Health check 



The ST sends the ST HEALTH CHECK INDICATION message to the SAM periodically. There is no strict 
requirement on the length of the period however it should be 1 second. The SAM shall respond with the ST HEALTH 
CHECK RESPONSE. 

6.1 .2 Frame count maintenance 

The ST shall send the Frame count at the start of each uplink frame using the ACF creation frame count message. The 
SAM shall use the latest Frame Count sent by the ST to process subsequent ACF Creation Indication Messages. The 
Frame count field is the current 35-bit uplink frame number in TOD [39, 5] format, as specified in TS 102 188-7 [2]. 

The ST shall send this message to the SAM within 100 )iseconds of the start of each uplink frame. 
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6.1.3 ACF procedure 



The ST shall send packet header information to the SAM, for both of the RSM-A packets contained in the uplink block 
that the ST is preparing to transmit, using the ACF CREATION INDICATION message. 

If the SAM approves the request, it shall respond with an ACF CREATION RESPONSE message containing the ACF 
field. The ST shall append this ACF to the MAC block before transmission to the satellite. The ST shall not transmit a 
MAC block to the satellite without an ACF field. 

The SAM responds to the ST with an ACF CREATION FAILURE message if the ACF cannot be computed. 

The following clause outlines the timing requirements for the ACF generation process. The timing diagram for the 
process is illustrated in figure 6.1. 

The diagram illustrates activity on the USB interface bus between the host and the SAM, as well as the processing that 
is performed by the SAM. The host initiates all activity on the USB bus, and the SAM behaves as a USB device. 

The process involves the following steps, and must be completed within one 16 Mbps code block period, which is 
87,8 |is. Figure 6.1 shows this code block period, or epoch: 

1) Transfer of data required to generate ACF from host to SAM. 

2) Processing of data by the SAM to generate the ACF. 

3) Extraction of the ACF data from the SAM by the host. 

The process is initiated by the host at the beginning of each epoch. In figure 6.1, this occurs at |is and again at 87,8 |is. 
The host must generate the Out Token within 1 |is of the beginning of each epoch (Icon 1). The host will then generate 
the Out Data packet. The SAM will receive the Out Data Packet, and acknowledge receipt to the host via an ACK 
message. The entire Out Data period will not exceed 17,74 |is under worst case conditions, which include a maximum 
number of zero insertions occurring on the USB interface (Icon 2). 

Once the SAM has acknowledged receipt of the Out Data, it is allocated 47 |is to process the data, generate the ACF, 
and make it available in its USB FIFO (Icon 3). This point must occur no later than 65,74 |is into the epoch (Icon 4). 
The SAM may continue code execution after it has filled its USB FIFO at Icon 3, provided it has completed execution 
under interrupt prior to Icon 6. This time period may be used for functions such as statistics gathering, and is shown as 
Icon 10. 

The host will begin initiation of the In Token 72,5 |is into the epoch period (Icon 5). The host must begin physical 
generation of the In Token onto the USB bus no later then 73,5 |is into the epoch period (Icon 6). In a worst case 
scenario, with a maximum number of zero insertions occurring during the In Data period, the In Data period will last 
12,3 |is (Icon 7). This will allow the In Data period to terminate at least 2 |js prior to the end of the epoch (Icon 8). 
Overall, this leaves a minimum margin of 6,76 |as between the In Data being available at the SAM and the generation of 
the In Token. 

Table 6.1 contains the timing requirements for this interface. All numbers are in microseconds. 

Table 6.1 



Icon 


Description 


Duration ((xsec) 


Epoch 
Point 


IVIin 


Max 


1 


Delay from beginning of epoch to generation of Out Token by the host 





1 


N/A 


2 


Out Data period 


16,74 


17,74 


N/A 


3 


SAIVI ACF generation period 




47 




4 


Latest point at which SAIVI must have In Data available for host 






65,74 


5 


Time point at which host will initiate In Data period 






72,5 


6 


Latency from (5) to appearance of In Token on bus 




1 




7 


In Data Period 


11,8 


12,3 




8 


End of In Data period to end of epoch 


2 


3,5 




9 


IVIargin available between In Data available at SAIVI and initiation of In Token 
by host 


6,76 
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Figure 6.1 : ACF timing diagram 

6.1 .4 Bandwidth Request procedure 

The ST requests Bandwidth from the satellite based on the policies that it signed up for and received from the NOCC 
during the registration process. The SAM ensures that the ST adheres to these policies and therefore will not sign 
requests that are not within these guidelines. The SAM shall approve requests that agree with the policy permitting the 
ST to send a message to the satellite requesting a bandwidth allocation. The BANDWIDTH REQUEST INDICATION 
message contains bytes 16-63 of the air interface bandwidth request message as described in TS 102 189-2 [3]. 

The SAM shall return an Integrity Check code within the BANDWIDTH REQUEST RESPONSE message if the ST is 
permitted to request the bandwidth. 

The SAM shall return a BANDWIDTH REQUEST FAILURE message to the ST with a failure code if the SAM rejects 
the ST's bandwidth request. The ST shall not request bandwidth from the satellite without a valid integrity code from 
the SAM. 



6.1 .5 Bandwidth Assignment procedure 



The satellite shall send bandwidth assignments to the ST. The ST shall filter each assignment based on the Bandwidth 
Control Satellite Terminal ID (BCSTID) (as specified in TS 102 189-2 [3]) contained in each assignment and send this 
assignment information to the SAM using the BANDWIDTH ASSIGNMENT INDICATION message. 

The SAM will use data from the BANDWIDTH ASSIGNMENT INDICATION message to subsequently determine 
which data packets it shall approve for transmission. Each BANDWIDTH ASSIGNMENT INDICATION message may 
contain up to 9 assignments. 

A BANDWIDTH ASSIGNMENT RESPONSE message is sent to the ST if the bandwidth assignment indication is 
successful and the SAM has stored all the assignments. 

If the SAM rejects all or some of the assignments, it shall send a BANDWIDTH ASSIGNMENT REJECT message to 
the ST. 

6.1 .6 Bandwidth Request and Assignment timing requirements 

The following clause outlines the timing requirements for the Bandwidth Request (BR) and Bandwidth Assignment 
(BA) message interface with the SAM. The timing diagram for these processes is illustrated in figure 6.2. 

The diagram illustrates activity on the USB interface bus between the ST host and the SAM, as well as the processing 
that is performed by the SAM. The host initiates all activity on the USB bus, and the SAM behaves as a USB slave. The 
diagram shows timing for both BA and BR cycles. 

The process involves the following steps, and must be completed within one half of a 2 Mbps code block period, which 
equates to 220 |is. Figure 6. 1 shows this Vi code block period, or epoch. 
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During the epoch period, the interface must be able to support either one BA transaction or one BR transaction. Each of 
these transactions has slightly different timing requirements. Both transactions operate using the following 3 steps: 

1) Transfer of data required from host to SAM via an Out transaction. 

2) Processing of data by the SAM, for either B A or BR. 

3) Extraction of the response from the SAM by the host via an In transaction. 

The entire process is initiated by firmware in the host at the beginning of each epoch. In figure 6.2, this occurs at |is 
and again at 220 |is. The host must generate the Out Token within 1 |is of the beginning of each epoch (Icon 1). The 
host will then generate the Out Data packet. The SAM will receive the Out Data Packet, and acknowledge receipt to the 
host via an ACK message. The entire Out Data period will not exceed 52 |is for a BR cycle or 55 |as for a BA cycle, 
under worst case conditions. The worst case condition includes a maximum number of zero insertions occurring on the 
USB interface. These time periods are shown by Icon 2 for a BR transaction and Icon 8 for a BA transaction. 

Once the SAM has acknowledged receipt of the Out Data, it is allocated 138 137 |is to process a BR message (Icon 3), 
or 134 [IS to process a BA message (Icon 9). This processing is considered to have ended when the SAM has loaded the 
data to be returned to the host in its USB buffer, and has set the TX_PKT_RDY bit. This point must occur no later than 
190 |is into the epoch (Icon 4) for either BA or BR transactions. The SAM may continue code execution after it has 
filled its USB FIFO at Icon 4, provided it has completed execution under interrupt prior to the end of the period denoted 
Icon 6 at 212 |is. 

For either BA or BR transactions, the host firmware will begin initiation of the In Token 192 |is into the epoch period 
(Icon 5 and Icon 10). The host must begin physical generation of the In Token onto the USB bus within 1 |is (Icon 6). In 
a worst case scenario, with a maximum number of zero insertions occurring during the In Data period, the In Data 
period will last 20 |is and end at 213 [is into the epoch (Icon 7). This will allow the In Data period to terminate at least 
7 |is prior to the end of the epoch. 

Table 6.2 contains the timing requirements for this interface. All numbers are in microseconds. 

Table 6.2: Bandwidth Request and Assignment interface timing requirements 



Icon 


Description 


Duration (|j.sec) 


Epoch 
Point 


IVIin 


IVIax 


1 


Delay from beginning of epoch to generation of Out Tol<en by the host 
(BR and BA) 





1 


N/A 


2 


Out Transaction period, BR 


46 


52 


N/A 


3 


SAIVl BR Processing period 




137 




4 


Latest point at which SAIVl must have In Data available for host 
(BR and BA) 






190 


5,10 


Time point at which host will initiate In Transaction (BR and BA) 






192 


6 


Latency from (5) to appearance of In Token on bus 




1 




7 


In Transaction Period (BR and BA) 


13,7 


20 




8 


Out Transaction period, BA 


49 


55 




9 


SAIVl BA Processing period 




134 




11 


Latest point at which In Token phase will complete 






213 
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Figure 6.2: Bandwidth Request and Assignment timing diagram 



6.1.7 Registration 



The ST sends an ST REGISTRATION INDICATION message to the SAM to initialize the registration process. If ST is 
already registered, the SAM sends an ST REGISTRATION COMPLETE message to the ST informing it of the 
registration status. If ST is not registered, SAM initiates the registration process with the NOCC. The ST treats these 
messages transparently as described in clause 7, but shall use the SA-supervisory contention channel as described in 
TS 102 189-2 [3]. The ST shall transition from the DEREGISTERED state to the REGISTRATION INITIATED state 
as described in TS 102 189-1 [4]. 

If the registration is successful, the SAM informs the ST via the ST REGISTRATION COMPLETE message. The ST 
shall transition from the REGISTRATION INITIATED state to the REGISTERED state as described in 
TS 102 189-1 [4]. 

If the registration fails, the SAM shall send a ST REGISTRATION FAILURE BACKOFF message to the ST. This 
message contains a backoff timer value. The ST shall start the backoff timer. Upon timer expiry, the ST shall resend the 
ST REGISTRATION INDICATION message to the SAM. 
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6.1.8 De-registration 



As described in TS 102 189-1 [4], the NOCC may deregister an ST. To do this, the NOCC shall send an encrypted 
message to the SAM/ST to deregister the ST. Upon reception of this message, the SAM shall clear the keys, registration 
and configuration information on the ST and send the NOCC a de-registration response as an acknowledgement. The 
SAM shall also inform the ST via a DE-REGISTRATION STATUS message to inform the ST that it has been de- 
registered. The ST shall transition from any substate of the REGISTERED state to the DEREGISTERED state as 
described in TS 102 189-1 [4]. 



Management messages 



7.1 



General 



The SAM communicates to the NOCC through the ST. These messages are transparent to the ST and are always 
encrypted by the SAM. The NOCC sends messages to the SAM through the ST and these messages are also always 
encrypted. The ST shall strip the ST-SAM header from all messages received from the SAM and destined for the 
NOCC. The ST shall add UDP/IP headers and management protocol headers as required. 



7.2 Segmentation and reassembly 



Certain management messages are longer than the 64 byte limit of the USB interface. These messages are segmented as 
shown in figure 7.1 after the ST-SAM header is added. Each first segment is 60 bytes and both an LI header and an H2 
header are added such that the H2 header is in byte and the LI header is contained in bytes 1-3. Each middle segment 
is 63 bytes and only an H2 header is added such that the H2 header is in byte 0. Each last segment is 63 bytes or less 
and only an H2 header is added in byte 0. A first and last segment is 60 bytes or less and both an LI and an H2 header 
are added such that the H2 header is in byte and the LI header is in bytes 1-3. Segments from one message shall not 
be combined with segments from another message. 



ST-SAM Header 



H2 plus LI Header 




H2 Header only 



64 byte USB packets 

Figure 7.1 : Segmentation and reassembly of management messages 



8 



Message formats 



The ST-SAM communication shall adhere to the format defined below. This clause will describe the messages 
exchanged between the Satellite Terminals (ST) and the Security Access Module (SAM) and to define the rules under 
which they communicate. 
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8.1 Packet orcjer of presentation 



The order of presentation or transmission of packets on the ST-SAM interface is in consecutive byte number, starting 
with byte (header) and ending with byte N. The transmit order of presentation of the bits within each byte of a packet 
is MSB first (bit 7) and LSB last (bit 0). The packets are transmitted in order as shown by the direction of transmission 
in figure 8.1. 



ByteO 



Byte 1 



(MSB) (LSB)I(MSB) (LSB)I(MSB) (LSB) 



Byte 2 



ByteN 

l(MSB) (LSB)I 



Time 



Figure 8.1 : Packet byte and bit order of presentation 



8.2 Order of bits within a field 

The order of bits within a field shall be "big-endian" or network byte order as illustrated in figure 8.2. 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bits 


Bit 2 


Bit1 


(LSB) 
BitO 


Byte 


















N 










27 


26 


25 


24 


N + 1 


23 


22 


21 


20 










N + 2 


















N + 3 



Figure 8.2: Order of bits within a field 



8.3 IVIessage types 



Table 8.1 lists the message types which traverse the interface between the SAM and the ST. Only those messages which 
either originate at the ST and terminate at the SAM or originate at the SAM and terminate at the ST are described in this 
clause. 

Table 8.1 : Message types 



Message type 


Source- 
Destination 


Msg type value 


BANDWIDTH ASSIGNMENT INDICATION 


ST-SAM 


1 


BANDWIDTH ASSIGNMENT RESPONSE 


SAM-ST 


2 


BANDWIDTH ASSIGNMENT FAILURE 


SAM-ST 


3 


BANDWIDTH REQUEST INDICATION 


ST-SAM 


4 


BANDWIDTH REQUEST RESPONSE 


SAM-ST 


5 


BANDWIDTH REQUEST FAILURE 


SAM-ST 


6 


ACF CREATION INDICATION 


ST-SAM 


7 


ACF CREATION RESPONSE 


SAM-ST 


8 


ACF CREATION FAILURE 


SAM-ST 


9 


ACF CREATION FRAME COUNT INDICATION 


ST-SAM 


255 


ST REGISTRATION INDICATION 


ST-SAM 


10 


ST REGISTRATION COMPLETE 


SAM-ST 


15 


ST REGISTRATION FAILURE BACKOFF 


SAM-ST 


17 


SAM DEREGISTRATION STATUS 


SAM-ST 


21 


ST HEALTH CHECK INDICATION 


ST-SAM 


34 


ST HEALTH CHECK RESPONSE 


SAM-ST 


35 
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8.4 



Error codes 



The error codes are listed in table 8.2 per protocol category. 



Table 8.2: Error codes 



Protocol class 


Error 


Error code 
value 


Generic error codes in SAIVI 


InvalidSAMESN 


1 


GorruptedlVlessage 


2 


Unexpected IVIessage 


3 


InvalidlncominglVlessage 


7 


IVlessagePacl<Unpacl<Error 


8 


NoCurrentSessionKey 


9 


registration error code 


NOCCAuthenticationFailure 


26 


ChallengeWaitTimeout 


27 


ResponseWaitlimeout 


28 


NotRegistered 


29 


bandwidth assignment error 
code 


BA SessionKeysFailure 


76 


BA OutOfRange 


77 


BA InvalidSTId 


78 


BA FailedAlntegrity 


79 


bandwidtli request error code 


BR SessionKeysFailure 


101 


BR UndefinedSTSourcelD 


102 


BR InvalidRequestRate 


103 


BR InvalidRequestlype 


104 


BR InvalidFrameCount 


105 


BR InvalidNumSlots 


106 


BR InvalidNumRequest 


107 


BR InvalidUplinkCelllD 


108 


BR BRICGenerationFailure 


109 


ACF request error code 


ACF SessionKeysFailure 


126 


ACF InvalidSTSourcelD 


127 


ACF InvalidDestination 


128 


ACF InvalidChannel 


129 


ACF InvalidSlot 


130 


ACF InvalidFrameNumber 


131 


ACF ContentionChannelConflict 


132 


ACF ContentionChannelUsage 


133 


ACF CONUSRequestlnvalid 


134 


ACF PayloadReplicatorRequestlnvalid 


135 


ACF DESComputationError 


136 


ACF InvalidHVULRequest 


137 


Generic error codes 


RNGProcessorError 


253 


OutOfSequence 


254 


UnknownError 


255 



8.5 Message header formats 
8.5.1 SAM-ST header 

The ST-SAM communication will adhere to the format defined below for communications between the two entities. 
This SAM-ST header is attached to the each message between ST and SAM (the exceptions to this rule are the ACF 
Creation Indication, Response, Failure and Frame Count Indication). It appears before the SAM Security header and 
message data structure. The SAM-ST header is not encrypted. 



£75/ 



17 



ETSI TS 102 189-3 VI. 1.1 (2004-03) 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


msgType 





transID 


1 


^r.^\ r^^ntl^ 


2 








iiioyi_ci lyiii 








3 



Figure 8.3: SAM-ST header format 

8.5.1.1 transID 

The transID is an integer value used to identify the response to a certain message. 



8.5.1.2 



msgLength 



The msgLength is the total length of the message (including messages that span multiple packets) excluding the 
SAM-ST header. 

8.5.2 H2 header 

All messages from the ST to the SAM and all response or failure messages from the SAM to the ST will have a H2 
header at the beginning of the message. 



8.5.2.1 



ST -> SAM direction 



The length of the H2 header is 4 bits for all messages from the ST to the SAM. The format is given in figure 8.4. Values 
are defined in table 8.3. 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


H2 header 


Spare (if L1 header is present) 






Figure: 8.4: H2 header format ST -> SAM direction 



Table 8.3: H2 header definition for ST -> SAM direction 



Function 


Value 


Description/Comment 


ACF 


0000 


ACF creation indication 


BA 


0001 


Bandwidth Allocation 


BR 


0010 


Bandwidth Request 


NullO 


0011 


Null Data, other data are not allowed to be written to SAIVI's TX FIFO 


Null 1 


0100 


Null Data, other data are allowed to be written to SAIVI's TX FIFO 


F/LO 


0101 


First and Last packet, other data are not allowed to be written to SAIVI's 
TX FIFO 


F/L1 


0110 


First and Last packet, other data are allowed to be written to SAIVI's TX FIFO 


FO 


0111 


First packet, other data are not allowed to be written to SAIVI's TX FIFO 


F1 


1000 


First packet, other data are allowed to be written to SAIVI's TX FIFO 


LO 


1001 


Last packet, other data are not allowed to be written to SAIVI's TX FIFO 


L1 


1010 


Last packet, other data are allowed to be written to SAIVI's TX FIFO 


MO 


1011 


Middle packet, other data are not allowed to be written to SAM's TX FIFO 


M 1 


1100 


Middle packet, other data are allowed to be written to SAM's TX FIFO 


Frame Count 


1101 


Frame counter 


reserved 


1110 




reserved 


1111 
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8.5.2.2 SAM -> ST direction 

The length of the H2 header is 8 bits for all messages from the SAM to the ST. The format is given in figure 8.5. 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


C 


spare 


F/L 


Function 






Figure 8.5: H2 header format for the SAM -> ST direction 

8.5.2.2.1 Function field 

The function field specifies the message type per table 8.4. 

Table 8.4: Function field definition 



Function 


Value 


ACF Response 


000 


Bandwidth Allocation 


001 


Bandwidth Request 


010 


Other Data 


oil 


Null 


100 


Reserved 


Other values 



8.5.2.2.2 



F/L field 



The F/L field specifies whether the packet is the first, middle or last packet of a data message per table 8.5. ACF 
response, Bandwidth allocation and bandwidth request messages shall always fit within one packet and the F/L field 
shallbecodedas"ll". 

Table 8.5: F/L field definition 



definition 


Value 


First packet 


10 


Middle packet 


00 


Last packet 


01 


First and last packet 


11 



8.5.2.2.3 C bit 

The C bit interpretation is conditional on the value of the function field. 

If the function is ACF response then C = 1 indicates ACF pass and C = indicates ACF fail. 

If the function is bandwidth allocation or bandwidth request then this bit is unused. 

If the function is other data or null then the C bit acts as a flow control bit. If C = 1, the SAM is ready to receive more 
data and if the C = then the SAM is not ready to received more data. 

8.5.3 L1 header 

The LI header accompanies the H2 header for all messages between the ST and the SAM except the messages related 
to the ACF. The length of the LI header is 3 bytes. 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


spare 


TMF 





Length 


1 


















2 



Figure 8.6: L1 header format 
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8.5.3.1 



TMF 



The TMF field is the target message FIFO address for which the message is intended in the SAM -> ST direction and 
the source TMF address for messages in the ST -> direction indicating to the SAM to which address the SAM response 
should be sent. 



8.5.3.2 



Length 



The length field is defined as the length in bytes of the SAM- ST message plus 4 for the first H2 header and the LI 
header. H2 headers prepended to any subsequent segments are not included in the length field value. 

8.6 Message formats 
8.6.1 ACF creation indication 

The ACF CREATION INDICATION message is sent by the ST to the SAM to request an ACF code for an RSM-A 
packet. 

LI Header present: No 

ST-S AM Header present: No 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


H2 header 


Sub-band designator 





HVUL Carrier designator 


1 


MAC lieader information 1 


2 


3 


4 


5 


6 


MAC lieader information 2 


7 


8 


9 


10 


11 


CGID index Spare Time slot number 


12 



Figure 8.7: ACF CREATION INDICATION message format 

8.6.1 .1 Sub-band designator 

The Sub-band designator field is defined in TS 102 188-5 [1]. 

8.6.1.2 HVUL bit 

The HVUL bit defines the MAC mode the terminal will use to transmit the packet. If the terminal is using HVUL mode, 
the HVUL bit = " 1". If the terminal is using BoD mode, the HVUL bit = "0". 

8.6.1.3 Carrier designator 

The Carrier designator field is defined in TS 102 188-5 [1]. 



8.6.1.4 



MAC header information 



The MAC header information field contains the first five bytes of the 8-byte MAC packet header. The MAC -packet 
header is defined in TS 102 189-2 [3]. The MAC header information does not include the Source ID, see 
TS 102 189-2 [3]. 
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8.6.1.5 



CGID index 



Instead of passing the 15 bit CGID field across the interface, the ST shall pass a two bit index field, since there are only 
three possible CGIDs for any transmit opportunity. The SAM already has the CGID values. 

8.6.1 .6 Time slot number 

The Time slot number field is defined in TS 102 189-2 [3]. 

8.6.2 ACF creation response 

The output of the Data Transmission process is an Access Control Field (ACF) code that is 4 bytes. 
LI Header Present: No 
SAM-ST Header Present: No 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


H2 header 





ACF 


1 


2 


3 


















4 



Figure 8.8: ACF CREATION RESPONSE message format 

8.6.3 ACF creation failure 

The SAM responses to the ST with a failure message when the ACF cannot be computed. 
LI Header Present: No 
SAM-ST Header Present: No 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


H2 header 





Failure Code 


1 



Figure 8.9: ACF CREATION FAILURE message format 

8.6.4 ACF creation frame count incJication 

The ST will send the Frame count (35 bits) at the beginning of each frame. The SAM will use the latest Frame Count 
from the ST to process subsequent ACF CREATION INDICATION Messages. 

LI Header present: No 

SAM-ST Header Present: No 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


H2 header 


spare 









1 


Frame Count 


2 




3 




4 



Figure 8.10: ACF CREATION FRAME COUNT INDICATION message format 
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Frame Count 

The Frame count field is tlie current 35-bit uplink frame number in TOD [39, 5] format, see TS 102 188-7 [2]. 

8.6.4A ST health check indication 

The ST HEALTH CHECK INDICATION message is sent by the ST to SAM to check the current registration status of 
ST. 

LI Header present: Yes 

SAM-ST Header Present: Yes 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


ACF IMF 





BR/BA IMF 


1 


Other IMF 


2 



Figure 8.1 1 : ST HEALTH CHECK INDICATION message format 

8.6.5 ST health check response 

The ST Health Check Response message is sent by the SAM to ST in response to an ST Health Check Indication. 
LI Header present: Yes 
SAM-ST Header Present: Yes 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Error Code 





1 


2 


3 


Boot SW version 


4 


Boot SW ICD version 


5 


6 


7 


8 


Operation SW version 


9 


Operation SW ICD version 


10 


11 


12 


13 


RS 1 CK 1 Spare 


14 



Figure 8.12: ST HEALTH CHECK RESPONSE message format 

8.6.5.1 Return code 

The Error Codes are defined in clause 8.4. 

8.6.5.2 Boot SW version 

The Boot SW Version number is a configurable parameter in the SAM. 

8.6.5.3 Boot SW ICD version 

The bootSwICDVersion is a configurable parameter in the SAM. 
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8.6.5.4 Operation SW version 

The operationSwVersion is a configurable parameter in the SAM representing the operational software version. The 
value of this parameter is "0" if the SAM does not have operational software. 

8.6.5.5 Operation SW ICD version 

The operationSwIcdVersion is the SAM-NOCC interface version which the SAM supports. 



8.6.5.6 



RSbit 



The RS bit is the registration status of the ST. If the ST is registered the value = "1" and if the ST is not registered the 
value = "0". 



8.6.5.7 



CKbit 



The CK bit indicates whether or not the SAM has CP Keys. If the SAM has valid keys the value = " 1 " and if the SAM 
does not have valid keys the value = "0". 

8.6.6 Bandwidth Assignment indication 

The ST receives Bandwidth assignments from the satellite in a Bandwidth assignment message 

(see TS 102 189-2 [3]). The ST shall forward this message to the SAM for verification. The SAM will use data from the 
bandwidth assignments to determine which data packets it should subsequently approve for transmission. There can be 
up to 9 assignments per Bandwidth assignment message. However, each assignment contains a BCSTIDand an ST shall 
filter these messages and only send to the SAM, those assignments which are addressed to that ST. 

LI Header present: Yes 

SAM-ST Header Present: Yes 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Uplink frame number 





Number of assignments 


1 


IF version 


2 


Assignment field #1 


3 


4 


5 


6 


7 


8 


9 


10 


11 


... other assignment fields 
(optional) 








TOD check 


9m + 3 






















9m + 6 



8.6.6.1 



Figure 8.13: BANDWIDTH ASSIGNMENT INDICATION message format 



Uplink frame number 



The frame number field is an integer value representing the uplink frame number for which the assignments contained 
in the message are valid. The upUnk frame number uses TOD [12, 5] format, TS 102 188-7 [2]. 
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8.6.6.2 Number of assignments 

Number of assignments contained in the message. This value cannot exceed 5. 

8.6.6.3 IF version 

Interface Version. 

8.6.6.4 Assignment field 

The assignment field is defined in TS 102 189-2 [3]. 

8.6.6.5 TOD check 

The TOD check is contained in the bandwidth assignment message which the ST receives from the satellite. 
See TS 102 189-2 [3]. 

8.6.7 Bandwidth Assignment response 

The BANDWIDTH ALLOCATION RESPONSE message is sent to the ST if the BANDWIDTH ALLOCATION 
INDICATION is successful and the SAM has stored all the allocations properly. The ST is not waiting for any response 
from the SAM but the SAM sends the message nevertheless, to indicate that the storage of the bandwidth allocations 
has been successful. A NULL message is sent to the ST to complete the interface requirements. 

LI Header Present: Yes 

SAM-ST Header Present: Yes 

8.6.8 Bandwidth Assignment failure 

The SAM sends the BANDWIDTH ASSIGNMENT FAILURE message to the ST if the SAM did not receive the 
Bandwidth allocations correctly. The GeneralFailureCode represents general failure code and does not attribute to any 
particular allocations. The AllocationFailureCode is specific to one of the five -bandwidth allocations. The index 
indicates which allocation has failed and the value indicates why it failed. 

LI Header Present: Yes 

SAM-ST Header Present: Yes 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


General error code 





Assignment #1 error Code 


1 






Assignment #m error code 


m 



Figure 8.14: BANDWIDTH ASSIGNMENT FAILURE message format 



8.6.8.1 



Failure code 



The General and assignment specific error codes are described in clause 8.5. The index indicates which allocation has 
failed and the value indicates the error code. It may be possible that one allocation may be successful and the other 
produces an error. An assignment error Code of zero"0" indicates that there is no failure corresponding to that 
assignment. The number of assignment failure codes, m, refers to the number of assignments in the corresponding 
BANDWIDTH ASSIGNMENT INDICATION message. 
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8.6.9 Ban(dwi(dth Request in(dication 



Ll Header Present: Yes 
SAM-ST Header Present: Yes 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Frame count 





3 


Bandwidth request header 


4 


9 


Bandwidth request data #1 


10 


15 


Bandwidth request data #2 


16 


21 


Bandwidth request data #3 


22 


27 


Bandwidth request data #4 


28 


33 


Bandwidth request data #5 


34 


39 


Spare 


40 


















48 



Figure 8.15:BANDWIDTH REQUEST INDICATION message format 

8.6.9.1 Frame count 

The frame count format is specified in TS 102 189-2 [3]. 

8.6.9.2 Bandwidth request header 

The bandwidth request header format is specified in TS 102 189-2 [3]. 

8.6.9.3 Bandwidth request data 

The bandwidth request data field format is given in TS 102 189-2 [3]. 

8.6.10 BancJwicdth Request response 

The output of the Bandwidth Request process is a Bandwidth Request Integrity Check (BRIC) code which is 4 bytes 
plus ST-SAM message overhead. 

Ll Header Present: Yes 

SAM-ST Header Present: Yes 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bits 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Integrity check 





1 


2 


3 


ABkey 






spare 








4 



Figure 8.16: BANDWIDTH REQUEST RESPONSE message format 
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8.6.10.1 Integrity check 

The integrity check is a check field created by the SAM. The ST shall include this information within the bandwidth 
request message it transmits to the satellite. The satellite shall reject all bandwidth requests which do not have a valid 
integrity check field. 

8.6.10.2 ABKey 

The AB key bit indicates the key used to calculate the Integrity Check, A = 0, B = 1. The ST shall include this 
information in the bandwidth request message it transmits to the satellite. 

8.6.11 BandwicJth Request Failure 

This message indicates the failure code or the failure reason whenever a bandwidth request to the SAM fails to produce 
a Bandwidth Request Integrity Check code. 

LI Header Present: Yes 

SAM-ST Header Present: Yes 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Failure Code 






Figure 8.17: BANDWIDTH REQUEST FAILURE message format 

8.6.12 ST registration incdication 

The ST sends this message to the SAM to initialize the registration process. 
LI Header Present: Yes 
SAM-ST Header Present: Yes 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


challengeResponseTimeoutValue 





1 


registrationRequestTimeoutValue 


2 


















3 



Figure 8.18: ST REGISTRATION INDICATION message format 

8.6.1 2.1 ChallengeResponseTimeoutValue 

The challengeResponseTimeoutValue is a configurable parameter. 

8.6.1 2.2 registratlonRequestTimeoutValue 

The registrationRequestTimeout Value is a configurable parameter. 

8.6.13 ST registration complete 

The ST REGISTRATION COMPLETE message is sent by the SAM to the ST to inform the ST that Registration is 
complete and was successful. 

LI Header Present: Yes 

SAM-ST Header Present: Yes 
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(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


MC 


Spare 






Figure 8.19: ST REGISTRATION COMPLETE format 



8.6.13.1 



MCbit 



The MC bit is set to "1" if the registration process completes successfully and is set to "0" if the ST is already 
registered. 



8.6.14 ST registration failure backoff 



The ST REGISTRATION FAILURE BACKOFF message is sent to the ST by the SAM upon receiving the ST 
Registration Failure message from the NOCC. The SAM shall forward the error code and backoff timer value sent by 
the NOCC. 

LI Header Present: Yes 

SAM-ST Header Present: Yes 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Error Code 





1 


2 


3 


backoff Time 


4 


5 


6 


7 


Reserved 


8 



Figure 8.20: ST REGISTRATION FAILURE BACKOFF format 



8.6.14.1 Error Code 

The Error Codes are defined in clause 8.4. 



8.6.14.2 



backoff Time 



The backoff time is sent to the SAM by the NOCC in the message. It is in units of seconds and the minimum value is 
seconds and the maximum value is 1 000 seconds. 



8.6.15 SAM deregistration Status 



The SAM DEREGISTRATION STATUS message is sent by the SAM to the ST with the status of a de-registration 
command from the NOCC. 

LI Header Present: Yes 

SAM-ST Header Present: Yes 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Error code 





1 


2 


3 


Reserved 


14 



Figure 8.21 : SAM DEREGISTRATION STATUS format 
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8.6.15.1 Error code 

The Error Codes are defined in clause 8.4. 
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Annex A (informative): 
SAM pin layout 

A.1 SAIVI pin layout 

Table A. 1 displays one recommended implementation of pin assignments for the SAM chip. This implementation uses 
the JEDEC standard 24 pin SOIC package. 

Pins 1, 4 and 16 are chip ground. Pin 24 is the voltage supply for the chip. Pins 3, 6, 7, 12, 17 and 19 are signal inputs 
which are connected to ground. Pin 5 is the 48 MHz clock. Pins 20 and 21 are signal inputs pulled to logical level 1 
(+ 5 volts). Pins 8, 9, 10, 15, 18 and 22 are signal inputs which are left open. Pins 1 1 and 14 are the USB differential 
data. Pins 2, 13 and 23 are not used. 

Table A.I 



GND 


1 




24 


VCC + 5 V 


Not used 


2 




23 


Not used 


GND 


3 




22 


open 


GND 


4 




21 


+ 5V 


48 MHz 


5 




20 


+ 5V 


GND 


6 




19 


GND 


GND 


7 




18 


open 


open 


8 




17 


GND 


open 


9 




16 


GND 


open 


10 




15 


open 


D- 


11 




14 


D + 


GND 


12 




13 


Not used 
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Annex B (informative): 
Message flow diagrams 

B.1 Successful bandwidth request/assignment/data 
transfer 

Figure B.l shows the message flow diagram for both the ST-Satellite interface and the ST-SAM interface for a 
successful data transfer. The ST-Satellite bandwidth-on-demand procedures are described in TS 102 189-2 [3]. 
See clauses 6.1.3, 6.1.4 and 6.1.5 for a description of the procedures associated with the ST-SAM interface. 



Satellite 



ST-SatelHte 

interface 
MAC Part 2 



ST-SAM 

interface 

MAC Part 3 
ST SAM 

BANDWIDTH REQUEST INDICATION 



BANDWIDTH REQUEST RESPONSE 



Bandwidth request message 



Bandwidth assignment message 



Data 



AND WIDTH ASSIGNMENT INDICATIO ^ 
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Figure B.l : Successful data transfer 



B.2 Successful registration 



Figure B.2 shows the message flow diagram for both the SAM-NOCC interface and the ST-SAM interface for a 
successful registration. See clause 6.1.8 for a description of the procedures associated with the ST-SAM interface. The 
SAM-NOCC procedures are outside the scope of the present document. 
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Figure B.2: Successful registration 



B.3 Successful de-registration 



Figure B.3 shows the message flow diagram for both the SAM-NOCC interface and the ST-SAM interface for a 
successful de -registration. See clause 6.1.9 for a description of the procedures associated with the ST-SAM interface. 
The SAM-NOCC procedures are outside the scope of the present document. 
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Figure B.3: Successful de-registration 
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